store.exe -- Object <DN> was not found on the DC  -- practical consequences?
Our Exchange Server 2007 SP1 SCC mailbox service seems to be working properly (as far as we can tell), but we've been seeing these messages occasionally in the Application log for as long as the service has been up:Process STORE.EXE (PID=1234). Object<distinguished name> was not found on the Domain Controller DC1.our.domain. This may indicate a replication or permission issue.What is the practical consequence of this error message?What did Exchange try (and fail) to do, and when, if ever, should we start to worry about it? If the message indicates a temporary failure, we aren't particularly concerned about making the messages go away entirely--if that's even possible--but we want to be sure that something bad isn't happening without anyone really knowing.Thanks,..Jeff
August 30th, 2009 6:02pm

Hi Jeff, I would like to know whether you have read following article regarding the Event: http://www.microsoft.com/technet/support/ee/transform.aspx?ProdName=Exchange&ProdVer=8.0&EvtID=2128&EvtSrc=MSExchange+ADAccess&LCID=1033 I think the event indicated that Exchange Server is not able to locate the AD Object from the Domain Controller DC1.our.domain. Mike Shen TechNet Subscriber Support in forum If you have any feedback on our support, please contact tngfb@microsoft.com
Free Windows Admin Tool Kit Click here and download it now
August 31st, 2009 9:59am

Mike,I did, and I think you're right. It's almost certainly not the network, since the DCs and the Mailbox server are on the same subnet, possibly on the same switch. It doesn't seem to be replication--that seems to be OK.Although I'm afraid of hearing your answer, I must ask: if the Exchange Server cannot locate the AD Object, what object is it looking for, potentially? A user's mailbox? And if it can't find it, for whatever reason, is it discarding the e-mail? And would such an event be recorded somewhere else?Or is such an error message generated by more innocuous events?Thanks,..Jeff
August 31st, 2009 9:04pm

Hi Jeff,Would you please let me know whether you receive the Events like below? Process STORE.EXE (PID=4576). Object CN=Exchange,CN=3801,CN=Display-Templates,CN=Addressing,CN=org,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=com I would like to explain that these warning relate to language installed on the exchange which should not affect the mail flow. You can safely ignore the events In addition, please check diagnostic logging level on the Exchange Server. If you set the diagnostic logging to lowest, whether does the warning still persist? Mike Shen TechNet Subscriber Support in forum If you have any feedback on our support, please contact tngfb@microsoft.com
Free Windows Admin Tool Kit Click here and download it now
September 1st, 2009 2:02pm

Mike,Thank you! You answered the question that I asked, which turned out not to be the question that I wanted to ask.Yes, we do have those sorts of errors, and it's helpful to know that they don't interfere with mail flow. Despite what I had asked originally, the errors that we're more concerned about are the ones listing GUIDs rather than DNs, i.e. Process STORE.EXE (PID=3664). Object <GUID=NNNNNNNN-XYZ0-ABCD-3826-132435465768> was not found on the Domain Controller DC1.our.domain. This may indicate a replication or permission issue. We could check the GUIDs in AD (using AD Explorer) more easily if we knew what the corresponding attributename might be (e.g., objectGUID, msExchMailboxGuid, ?)I slogged through the Application Log and captured a batch of these GUIDs. There was one that I saw twice, and I suppose I might see more repetition. I checked a few and could not find them in AD, although AD Explorer makes you specify the attribute name for a value, and I tried only objectGUID and msExchMailboxGuid.Might the error be a result of appointments on shared Exchange calendars having attendees who have left the organization and no longer have mailboxes? Or something like that?I know the documentation talks about replication delay, but we don't create new user accounts at the rate that these messages appear, and we only have two DCs, in close proximity. I doubt that Exchange is asking about an object that was recently created and just hasn't made it to a particular DC.Thanks again,..Jeff
September 1st, 2009 10:36pm

Hi Jeff, Thanks for your response. After research our internal database, I do not find more information regarding the GUID indicated in the even 2128. Nevertheless, I do notice that the Event is received after increasing Diagnostic logging for MSExchange ADAccess. Therefore, would you please run following command on the Exchange Mailbox Server and post result here? Get-eventloglevel MSExchange ADAccess Mike Shen TechNet Subscriber Support in forum If you have any feedback on our support, please contact tngfb@microsoft.com
Free Windows Admin Tool Kit Click here and download it now
September 2nd, 2009 10:49am

Mike,All 8 of the categories are at the "Expert" level. Here's the listing for the first object in the collection(get-eventloglevel "MSExchange ADAccess" | fl ) :Identity : MSExchange ADAccess\GeneralIsValid : TrueObjectState : UnchangedName : GeneralNumber : 1EventLevel : ExpertI'm predicting (or hoping) that you're going to say that events beyond some level indicate minor messes in the configuration and aren't anything to worry about, particularly if they're hard to clean up. I'm OK with lowering the EventLevel if that's the case. I just don't want to miss anything important.Again, I'm guessing (or hoping) that these errors are related to items containing references to objects that no longer exist--the user is gone, the mail contact was deleted, etc.FYI, I didn't do the initial config of the servers, and it's possible that some debugging levels had been set very high with the intention of lowering them after a while...Jeff
September 2nd, 2009 7:13pm

Hi Jeff, Thanks for your response. I suggest you lower the Diagnostic Logging to default level to check whether the warning still persists. If the warning event is not received any more, I think that you could ignore the warning as the Exchange works well currently. I have reviewed serveral cases in our internal database, I do not find any problem which relate to the event.The default Diagnostic Logging for MSExchange ADAccess:MSExchange ADAccess\General LowestMSExchange ADAccess\Cache LowestMSExchange ADAccess\TopologyLowMSExchange ADAccess\Configuration LowestMSExchange ADAccess\LDAP LowestMSExchange ADAccess\Validation LowMSExchange ADAccess\Recipient Update Service LowestMSExchange ADAccess\Site Update LowestNevertheless, if you still have concerns regarding the event, I also suggest you submit a case to our PSS team who can deeply research the issue.Thanks,Mike
Free Windows Admin Tool Kit Click here and download it now
September 3rd, 2009 2:05pm

Mike,OK, thanks very much for your help. I'm still concerned about the event, since I don't know what can cause it to be logged. I'll consider submitting a case. Our rather vague problem is that users claim to lose e-mail fairly often. Nearly always, we can find the e-mail. The vast majority of the time, the e-mail is sitting in the Junk E-mail folder. In most other cases, the user has done something strange with rules that caused the message to be filed in an unexpected place, or discarded. Occasionally, theuser deleted the mailaccidentally, without noticing.In a small number of cases, one user will claim to send mail to another user, the message tracking logs will indicate that the e-mail was delivered, but no amount of searching finds the mail in the other user's mailbox, and the user either has no rules at all or has easily understood rules that wouldn't have touched the message in question. We have mailbox item retention set rather high here (30 days), so it's easy to go into a user's mailboxand try to recover things that the user has recently hard-deleted (shift-delete)--sometimeswe can't even find the messageusing that method of last resort.As for this thread, you've answered my questions. I just want to eliminate all obvious problems; getting clean Event Logs would be a good start.Thanks again,..Jeff
September 3rd, 2009 5:25pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics